Skip to content

Use normalized tuples for fallback calculation #19111

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

sterliakov
Copy link
Collaborator

Fixes #19105. I haven't checked this with namedtuples magic, nor am I certain that this is the best way.

This comment has been minimized.

@sterliakov sterliakov marked this pull request as ready for review May 19, 2025 02:11
@sterliakov
Copy link
Collaborator Author

@ilevkivskyi sorry to bother you again, I'd appreciate a review - this PR fixes a crash and you should be well familiar with the affected part. Thanks!

Copy link
Member

@ilevkivskyi ilevkivskyi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, unfortunately this whole normalization story is a bit tricky (partially because of design limitations of semanal_typeags.py). FWIW I think for now some "reactive" bug fixing is OK, but at some point we may need to think about tightening this a bit more.

# https://github.com/python/mypy/issues/19105
from typing import Unpack

class A(tuple[Unpack[tuple[int]]]): ...
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please also add a test for

class C(tuple[Unpack[tuple[int, ...]]]): ...

(unless there is already such test case)? I am not sure we properly handle such types. Also maybe test not just class creation, but some tuple ops as well, such as e.g. unpacking etc.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Surprisingly we don't have such a test too, but it was already working before my patch - *tuple[int, ...] is not a trivial unpack. But your feeling is overall correct - I'm able to make it crash with

a: A
tuple(a)

and also get a terrible diagnostic on

b: B
_, = b  # E: Variadic tuple unpacking requires a star target

despite B clearly not being variadic. I'll move this to draft for now, there's little benefit from merging a crash fix that causes a next one immediately...

@sterliakov sterliakov marked this pull request as draft May 19, 2025 20:40
@jorenham
Copy link
Contributor

jorenham commented Jul 1, 2025

Does this perhaps also cover (part of) #17282?

@sterliakov
Copy link
Collaborator Author

@jorenham probably not

This comment has been minimized.

@sterliakov sterliakov requested a review from ilevkivskyi July 5, 2025 18:10
@sterliakov sterliakov marked this pull request as ready for review July 5, 2025 18:10
Copy link
Contributor

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

Copy link
Member

@ilevkivskyi ilevkivskyi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LG, but I have one question.

@@ -102,6 +102,8 @@ def visit_type_alias_type(self, t: TypeAliasType) -> None:
# If there was already an error for the alias itself, there is no point in checking
# the expansion, most likely it will result in the same kind of error.
get_proper_type(t).accept(self)
if t.alias is not None:
t.alias.accept(self)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a duplicate work, did you try deleting the accept just above? (if you delete it, don't forget to update the comment)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That breaks one test:

[case testValidTypeAliasValues]
from typing import TypeVar, Generic, List

T = TypeVar("T", int, str)
S = TypeVar("S", int, bytes)

class C(Generic[T]): ...
class D(C[S]): ...  # E: Invalid type argument value for "C"

U = TypeVar("U")
A = List[C[U]]
x: A[bytes]  # E: Value of type variable "T" of "C" cannot be "bytes"

V = TypeVar("V", bound=int)
class E(Generic[V]): ...
B = List[E[U]]
y: B[str]  # E: Type argument "str" of "E" must be a subtype of "int"

Removing this line makes both errors on alias instantiation disappear. That's quite expected since get_proper_type calls _expand_once, so it is not equivalent to simply accepting the target alias - we do not want to ignore args here. We can limit that to only accepting if args are non-empty, but I don't think this can result in any significant speedup.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, this is kind of unfortunate. We already accept args in isolation at the very start (see super call), then we accept expansion, and finally the target in isolation. But I guess this is the price to pay for having both:

  • Support for unrestricted type vars in alias definitions
  • Doing some in-place patching in this visitor

@ilevkivskyi ilevkivskyi merged commit 2e5d7ee into python:master Jul 22, 2025
20 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

class S(tuple[*tuple[()]]) crashes mypy
3 participants